The issue #87 points out that in some edge cases the C14N can fail.
It is not a common case, even psalm don't recognize that c14n() can return false.

This problem can be reproduced by setting a namespace uri value as a defined xml entity.

<!DOCTYPE foo SYSTEM "foo.dtd" [
  <!ENTITY ns_foo "http://uri.tld/foo">
]>
<i:foo xmlns:i="&ns_foo;"/>

I append two cases to tests when C14N fails (using current providers):

• Identicals documents must assert equal
• Different documents must throw ComparisonFailure

To solve it, I separate @$document->loadXML($node->C14N()) into two steps: $c14n = @$node->C14N() and @$document->loadXML($c14n).
If $c14n === false then retry node to text conversion but without using canonicalization.

Observations:

• This is an edge case, C14N failing is very uncommon.
• DOMNodeComparator::nodeToText is always called with $canonicalize = true, DOMNodeComparator::assertEquals ignored the $canonicalize argument.
• The comparison on this cases (when C14N fails) is more strict, since canonicalization is not performed.
• Didn't remove the silent operator, and extended it to c14n() call. This is preserving the same behavior as before.

If you think is necessary I can try other approaches:

• Node canonicalization and xml loading capturing libxml errors, then throw an exception.
  This will require to add another exception that contains the libxml_get_errors() array, or,
  implode the errors into a single message and use the current SebastianBergmann\Comparator\RuntimException.

• If convert the node to text fails then throw a ComparisonFailure. This is like saying that $expected is different than $actual because the comparator is unable to perform the comparison.

• Change DOMNodeComparator::acept() and only return true if objects are DOMNode and the canonicalization don't fail. I don't like this approach because canonicalization can be very expensive.